Recent extensions to computer processors, such as the Intel Software Guard Extensions (SGX) for the x86 processor architecture, provide hardware support for secure application execution. Such extensions allow a user-mode application to create a protected region, known as an “enclave”, within the application's address space. The hardware provides confidentiality and integrity for an enclave, even from privileged malware and physical attacks on memory, through cryptography and hardware isolation of memory. In other words, SGX comprises a set of instructions and memory access changes to the Intel architecture that allow a process to create a protected region of its address space, known as an “enclave”, which provides hardware-enforced confidentiality and integrity protection for data and code against potentially-malicious privileged code or hardware attacks such as memory probes.
Unfortunately, in some implementations, this hardware protection does not extend to the secure execution of system software. For example, the stated intent of Intel SGX is to isolate trusted application components, completely removing privileged software, such as an OS or hypervisor, from the trusted computing base. See, for example, Frank Mckeen, et al., “Innovative Instructions and Software Model for Isolated Execution”, Proceedings of the Second International Workshop on Hardware and Architectural Support for Security and Privacy (HASP '13), Tel-Aviv, Israel, June 2013 (“McKeen”).
The first-generation version of Intel SGX is expected to support only the execution of unprivileged, user-mode instructions within an enclave. Moreover, as currently architected, an enclave must reside entirely within a single virtual address space, and protected memory cannot be shared across enclaves. As a result, these hardware extensions are not able to protect the code and data of system-level software that manages multiple address spaces, or executes privileged, kernel-mode instructions directly, including commodity operating systems (OSes) such as Linux and Microsoft Windows.
Nevertheless, most applications depend on a properly-functioning OS for various system services, including access to hardware I/O devices through abstractions such as files, sockets, and processes. Unfortunately, a compromised OS may attempt to undermine application security through malicious manipulation of the system call interface. This threat is described, for example, in Xiaoxin Chen, et al., “Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating Systems”, Proceedings of the Thirteenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS '08), Seattle, Wash., March 2008 (“Chen”); and Dan R. K. Ports and Tal Garfinkel, “Towards application security on untrusted operating systems”, Proceedings of the Third Conference on Hot Topics in Security (HOTSEC '08), San Jose, Calif., July 2008. As a result, secure applications must be designed explicitly to avoid leaking data to a potentially-hostile OS, which imposes a significant burden on application developers. Clearly, it would be desirable to help protect an OS from becoming compromised in the first place, such as by providing the same hardware-enforced confidentiality and integrity safeguards offered to applications.
Moreover, public cloud computing platforms, such as Amazon EC2 and Microsoft Windows Azure, typically execute customer computations as virtual machines (VMs). As is well known, A VM encapsulates both user-mode applications and kernel-mode OS system software within a single container. In virtualized environments, the term “guest” is commonly used to distinguish the layer of software running within a VM; a “guest OS” thereby manages applications and virtual hardware. The term “host” is commonly used to refer to the layer of software—often referred to as a “hypervisor” and/or virtual machine monitor (VMM), depending on the configuration—that manages VMs and physical hardware.
In public cloud environments, customers do not have physical control over the hardware on which their VMs are executing, making them vulnerable to both physical and software-based attacks by a malicious or compromised cloud service provider. As a result, there is a need to protect the integrity and confidentiality of entire virtual machines, containing both user-mode applications and kernel-mode system software.